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Warning  to  the  Unwary 

This  manual  is  intended  for  use  by  students  or  staff  faced 
with  the  problem  of  writing  packages  which  must  be  run  under  the 
Educational  Timesharing  System  -  ETS.   This  manual  assumes  a 
reasonable  idea  of  ETS  and  a  good  familiarity  with  the  PAL  assembly 
language.   It  is  designed  more  as  a  reference  manual  than  guide  to  ETS. 

Any  suggestions  for  improvement  will  be  sincerely  appreciated. 


IV 


Table  of  Contents 

Page 

I.   Introduction 1 

II.   Basic  Job  Structure 2 

A.  Dynamic  Relo  cat  ability 2 

B .  Minimum  Stack 2 

C.  Control  and  Communication  Structure 2 

III.   Code  Description 12 

A.  Dynamic  Relocatability 12 

B.  Register  Relocatability 12 

C.  COMWRD  and  RELPTR 15 

D.  Stack  Conventions 15 

E.  Processor  Status  Word  Manipulation 19 

F.  System  Buffer  Allocation 21 

G .  Anchor  Mode 21 

H.  Named  Code 23 

IV.   File  Handling 2k 

A.  File  Operation 2k 

B.  File  Request  Queue  Block  (FIRQB) 2k 

C .  Available  File  Operations 2k 

D .  Error  Return 33 

V .   Input-Output 3^ 

A.  General  Principles 3I4. 

B.  I/O  to  a  Serial  Device 36 


Page 

C.  File   I/O 1+2 

D.  Errors 1+5 

VI .      Special  EMT  Functions 1+7 

A.  .AUCHR 1+7 

B.  .BREAK 1+7 

C .  .  COFE 1+8 

D.  .BAR  and  .BAW ^8 

E .  .EXIT 1+9 

F.  .HOIST 1+9 

G.  .LOCK  and   .UNLCK 1+9 

H.       .NAME 51 

I .       .  STALL 51 

J.      .TTAPE  and   .TTRST 51 

K.       .WAIT 53 

L.       .FIND 53 

VII.  Use  of  Interrupts  and  Special  Functions 55 

A.  Interrupts 55 

B.  CNTL  V 55 

C.  CNTL  Q 55 

VIII .   System  Service  Routines 56 

A.  SETBBB 56 

B.  OCTOUT 56 

C .  SETFQ, 58 


vi 


Page 

D.  SIMESS 58 

E .  ENDTST 59 

F.  OCTIN 59 

G.  NAMEIN 60 

H.  BUFFER 60 

I.  CLRBUF 61 


VX1 


List  of  Figures 

Figure  Page 

II .  1  Job  Data  Block 3 

11. 2  File  Control  Block 6 

11. 3  Teletype  Device  Data  Block 7 

II. If  FIP  or  I/O  Error  Codes 10 

IV.  1  FIRQB  Structure 25 

IV. 2  The  BNF  Definition  of  a  Switch  List 31 

IV. 3  The  Buffer  Returned  on  Parsing  a  Switch  List 32 

V.l  Transfer  Control  Block  Structure 35 

V.2  XRB  Parameters  for  Using  the  Card  Reader 38 

V.3  Line  Printer  Character  Set kO 

VI. 1  Suggested  Stall  Times  for  Various  Devices 52 


Vlll 


List  of  Examples 

Example  Page 

11. 1  A  Routine  to  Count  the  Number  of  Active  Files/Devices 5 

11. 2  Routine  to  Extract  Device  Type  and  Branch  to  Special  Routine....   8 

111.1  Marking  Registers  Which  May  Contain  Absolute  Pointers Ik 

111. 2  Establishing  and  Referencing  Absolute  Locations  using  RELPTR....  l6 

111. 3  Construction  of  a  Disptach  Table  Containing  Absolute  Addresses 

at  Base  of  Stack 18 

III.ll-    Setting  Anchor  Mode 22 

IV. 1    Routine  to  Pack  a  File  String  into  a  FIRQB  and  Open  the 

File  on  Channel  2 26 

V.  1  A  Routine  to  Read  a  String  from  the  Teletype k3 

V.2  A  Routine  to  Output  a  Message  on  the  Teletype kk 

V.3  Finding  and  Reading  a  Particular  Disk  Block k6 

VI.  1  Use  of  Direct  Access  Read  -  DAR 50 

VI. 2  Setting  a  Wait  Condition 5k 

VIII. 1    Accepting  a  File  Name  and  Channel  From  the  Teletype  and 

Trying  to  Open  it 57 


ETS  System  User's  Guide 

I.   Introduction 

A.  Welcome  to  the  ETS  System  User's  group.   In  this  paper  we  hope  you 
will  find  anything  you  need  to  know  about  programming  under  ETS. 
However,  before  we  begin  to  explain  the  art  of  programming  for  ETS 
we  would  like  to  bring  up  a  few  items  of  ETS'  philosophy. 

1.  ETS  is  designed  for  use  by  students  who  are  not  acquainted  with 
the  use  of  a  computer.  Consequently,  we  must  assume  that  every 
student  input  is  possibly  in  error  and  check  it  accordingly. 

2.  Again  because  we  assume  that  students  know  nothing  about  the 
system,  we  want  to  keep  the  required  responses  very  short  and 
as  clear  as  possible. 

3.  In  the  interest  of  compatibility  with  DOS  we  will  use  names  and 
input  responses  as  much  as  possible  like  those  used  by  DOS. 

B.  The  system  code  which  you  write  for  ETS  will  be  run  without  the  use 

of  an  interpreter.   Since  the  PDP-11  has  no  protection  it  is  necessary 
that  all  system  code  be  bug  free. 

C.  Unlike  operating  systems  on  machines  which  have  hardware  memory 
protection  and  hardware  relocation,  ETS  is  a  "handshake"  monitor 
which  runs  in  conjunction  with  the  system  programs.   This  means 
that  system  programs  must  to  some  extent  be  conscious  of  the  ETS 
monitor  and  its  needs.   Similarly,  the  ETS  monitor  will  provide 
services  which  will  make  it  easier  for  the  system  program  to  run 
without  the  presence  of  hardware  memory  relocation. 


II.      Basic   Job   Structure 

A.  Dynamic  Relocatability 

All  jobs  in  ETS  are  considered  as  blocks  of  dynamically  relocatable 

code  (see  section  III. A)  with  an  addressing  space,  A,  0  <  A  <  lf000on 

*"   ~~     o 

where  n  is  the  number  of  blocks  of  core  assigned  to  the  job. 

B.  Minimum  Stack 

All  jobs  will  have  a  minimum  stack  size  of  ^00q  bytes  beginning  at 
user  location  0  (see  section  III.B). 

C.  Control  and  Communication  Structure 

In  line  with  the  "handshake"  principle  of  operation,  ETS  permits  jobs 
to  examine  the  control  variables  which  it  maintains,  in  order  to  know 
the  state  of  the  job  at  any  given  time.  While  the  user  may  examine 
the  control  variables  at  will,  he  must  not  change  them.  ETS  also 
provides  some  communication  variables  through  which  the  user  may 
communicate  his  wishes  to  ETS  and  vice  versa.   The  first  seven  items 
in  the  following  list  are  all  "read  only"  control  variables.   The 
last  three  are  communication  variables. 

1.  JOB  is  a  variable  of  length  1  byte  which  contains  a  user's  job 
index  or  job  number  (note  that  all  job  numbers  in  ETS  are  even 
numbers ) . 

2.  JOBDA  is  a  one  word  pointer  which  points  to  the  beginning  of  a 
l6  word  job  control  block  called  a  job  data  block  (JDB).   The 
job  data  block  is  the  basic  structure  which  ETS  uses  to  define 
the  state  of  a  user  job  at  any  given  time  (see  figure  II. l). 

3-   The  first  word  in  the  JDB  points  to  the  input-output  control 
block  (lOB).   The  IOB  is  an  eight  word  block  which  contains 
pointers  to  control  blocks  for  each  of  the  files  or  devices 
currently  in  use  by  a  given  user.  Each  of  the  eight  possible 
pointers  is  referred  to  as  a  channel.  Any  channel  which  contains 


JDIOB 

- 

Pointer  to  i/o  block 

0 

JDFLG 

- 

Job  status  flags 

2 

JDIOST 

- 

i/O  error  status 

k 

JDSP 

- 

Relative  user  stack 

6 

JDCPU 

- 

CPU  time  used 

10 

JDKCT 

- 

KILO-COEE-ticks  used 

12 

JDDEV 

- 

Device  time  used 

11+ 

JDSIZ1  - 
Next  size 

JJDSIZO 
in  K   1  Present  size  in 

K 

16 

JDUFD 

- 

Start  block  of  job's  UFD 

20 

JDPPN 

- 

Proj-Prog  number 

22 

JDSGNW 

- 

Unused 

2k 

JDSGMX 

- 

Unused 

26 

JDUFLG 

- 

User  comm.  flags 

30 

JDNAME 

- 

User  Prog  Identifier 

32 

JDANCR 

- 

Tie  User  Job  to 
Specific  Core  Location 

3h 

Unus 

ed 

36 

Figure  II. 1     Job  Data  Block 
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a  non-zero  pointer  is  currently  in  use;  thus,  a  user  may  check 
for  open  files  or  devices  by  interrogating  the  channels  and  checking 
for  non-zero  entries  (see  example  II. l).  Note  that  all  channels 
are  referred  to  in  ETS  as  channel  indexes  which  are  even  numbers 
and  may  be  used  as  an  index.  Thus,  channel  number  one  has  a 
channel  index  of  two. 

k.    fcb/ddb 

Each  open  file  is  controlled  by  a  16  word  block  called  a  file 
control  block  (FCB  -  see  figure  II. 2).  A  file  control  block  is 
pointed  to  by  an  entry  in  the  IOB  and  contains  sufficient  information 
to  allow  the  system  to  transfer  data  to/from  a  file  without  excessive 
disk  accesses.  Associated  with  each  device  is  a  device  data  block 
(DDB  -  see  figure  II. 3)  which  allows  the  system  to  control  the 
physical  device.  DDB's  are  created  at  system  initialization  and 
remain  uniquely  associated  with  the  device  from  then  on.  An  FCB 
is  created  only  when  a  file  is  opened  and  is  destroyed  again  when 
the  file  is  closed.   There  may  be  more  than  one  file  control  block 
for  a  given  file  assuming  that  more  than  one  user  has  opened  a 
particular  file.  However,  there  can  be  only  one  device  data  block 
for  a  device  at  any  given  time.   The  first  byte  of  an  FCB/DDB 
contains  a  handler  index  which  may  be  examined  to  find  the  device 
associated  with  the  block  (see  example  II. 2). 
5.   The  first  word  of  the  IOB  always  points  to  the  DDB  for  the  user's 
job  teletype.  Thus,  channel  0  is  designed  to  be  the  control 
teletype  for  the  user  job.  Note  that  channel  0  can  neither  be 
opened  or  closed  by  the  user. 


JOBDA 


=  XXX 


; System  variable  containing  pointer 
;to  job  data  block 


BEGIN: 


Bl: 


B2 


MOV 

@#JOBDA,  RO 

MOV 

(RO),RO 

CLR 

Rl 

TST 

(R0)  + 

BEQ 

B2 

INC 

Rl 

BIT 

#17,  RO 

BNE 

Bl 

;Pick  up  pointer  to  JDB — 

;use  absolute  addressing  to 

; system  variables 

; Point  to  IOB — address  is  multiple  of  ^Oq 

;Is  this  channel  open? 

;No,  don't  count  it 

;Yes,  count  it 

;Have  we  checked  8  channels? 

;No,  keep  trying 


Example  II. 1  A  Routine  to  Count  the  Number  of  Active  Files/Devices 


FCSTS 


FCTYPE 


FCASN        FCBC 
I 


FCSIZ 


FCNLB 


FCFLI 


FCFNB 


FCPW 


FCETC 


FCWND 


FCSEG1 


FCSEG2 


FCSEG3 


FCSEG^ 


FCSEG5 


FCSEG6 


FCSEG7 


Control  Information 


Current  Retrieval  Window 


FCTYPE 
FCSTS 


FCBC 


FCASN 

= 

3 

FCSIZ 

= 

k 

FCNLB 

= 

6 

FCFLI 

= 

10 

FCPNB 

= 

12 

FCPW 

= 

Ik 

FCETC 

= 

16 

FCWND 

= 

20 

FCSEG1 

= 

22 

FCSEGi 

= 

20+2i 

i/O  handler  index  -  disk  =  0 

Status  bits  for  file 

Bit  1=1  User  is  not  owner  of  file 

Bit  2=1  User  may  not  read  file 

Bit  3=1  User  may  not  write  file 

Block  count  for  current  transfer 

(He  can  only  get  1  block  at  a  time 

unless  he  does  a  direct  access  read/write) 

Location  of  file  name  block  in  UFD  (word  offset) 

#  of  segments  in  file 

Logical  block  number  of  next  block  to  read/write 

First  logical  block  in  window 

Disk  physical  segment  containing  name  block 

Disk  physical  segment  containing  current  window 

Miscellaneous  word.  Users  doing  a  direct 

read/write  put  current  memory  address  here 

UFD  address  of  next  retrieval  window 

Physical  segment  corresponding  to  FCFLI 

Physical  segment  corresponding  to  FCFLI+i 


Figure  II. 2  File  Control  Block 
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CD 


2 

6 

10 
12 
14 


Teletype 
DECtape 
Line   Printer 
Paper   Tape  Reader 
Paper  Tape  Punch 
Card  Reader 


Handler  Index 


0 

Status  and     '       Handler 
Access  Control         Index 

2 

Owner  Job 
Index 

k 

Time  Assigned  or  Inited 

6 

Carriage            Carriage* 
Vertical           Horizontal 
Position       ,      Position 

10 

Chain  Buffer       * 
Fill  Pointer-Input 

12 

Chain  Buffer 
Fill  Count -Input 

Ik 

Chain  Buffer       * 
Empty  Pointer-Input 

16 

Chain  Buffer 
Empty  Count -Input 

20 

Max  Buffer  Count 

22 

Chain  Buffer 

Fill  Pointer -Output 

2k 

Chain  Buffer 
Fill  Count -Output 

26 

Chain  Buffer 

Empty  Pointer -Output 

30- 

Chain  Buffer 
Empty  Count -Output 

32' 

* 
Max  Buffer  Count 

3k; 

36 

Init  CNT  for  Device 

o 

o 

t-3 

I 

CD 
-P 
•H 


CJ 

o 

0) 

i 


40 

O 

a 

•H 
II 

CD  <h 

l_ 


76543210 

Status  and  Access  Control 
Byte 


Indicates  Device  Dependent  Assignment 


Figure  II. 3  Teletype  Device  Data  Block 


CHNNDX: 


JOBDA   xxx 
.WORD   x 


; Pointer  to  JDB 

; Channel  index  set  by  user 


BEGIN: 


MOV 

@#JOBDA,  RO 

MOV 

(RO),RO 

ADD 

CRTODX,  RO 

MOVB 

@(RO)+,RO 

ADD 

RO,  PC- 

BR 

DISK 

BR 

TTY 

BR 

DTA 

BR 

LPT 

BR 

PTR 

BR 

FTP 

BR 

CDR 

Point  to  JDB 

Point  to  IOB 

Point  to  channel  desired 

Pick  up  handler  index- - 

use  sign  extension 

Branch  to  desired  handler 

0  =>  disk  (was  an  FCB) 

2  =>  teletype 

k  =>   DECtape 

6  =>  line  printer 

10  =>  paper  tape  reader 

12  =>  paper  tape  punch 

Ik   =>  card  reader 


Example  II. 2 


Routine  to  Extract  Device  Type 
and  Branch  to  Special  Routine 


6.  jbstat/jbwait 

In  order  to  implement  timesharing  it  is  not  sufficient  to  be  able 
to  start,  stop  and  switch  jobs.   Jobs  will  often  generate  conditions 
which  require  them  to  wait  for  some  later  event  (e.g.,  completion  of 
a  line  of  TTY  input).   It  is  very  inefficient  to  keep  restarting  a 
job  to  allow  it  to  check  for  the  occurrence  of  a  given  event.  A 
better  solution  is  to  set  some  type  of  flag  and  let  the  system 
watch  for  the  event,  then  wake  the  job  when  the  event  has  occurred. 
In  ETS  there  are  a  number  of  specific  events  on  which  a  job  might 
wait  (in  particular,  each  device  has  a  unique  event  associated  with 
it  as  does  the  file  processor  and  the  timer  service).  When  a  job 
is  created  it  is  assigned  2  status  words  ( JBSTAT/ JBWAIT )  to  indicate 
blockages  that  may  occur.  When  a  job  is  running  both  JBSTAT=1  and 
JBWAIT=1.  When  a  job  requests  a  service  for  which  it  must  be  blocked, 
JBWAIT  is  cleared  and  the  bit  associated  with  that  event  is  set  by 
the  system  event  routine  in  JBSTAT.   The  condition  that  a  job  be  able 
to  run  is  then  JBSTAT  *   JBWAIT  ^  0.   The  system  then  can  check 
JBSTAT  ^  JBWAIT  and  schedule  a  job  to  run  only  when  it  is  not  blocked. 
Note  that  a  job  will  then  run  if  any  one  of  a  number  of  blockages 
are  relieved;  it  will  not  wait  until  they  are  all  relieved. 

7«   IOSTS  is  a  one  word  pointer  to  a  job's  i/O  status  which  is  kept  in 

the  second  word  in  the  job  data  block.   This  word  contains  the  result 
of  the  last  i/O  or  file  operation  performed  by  the  job  (see  figure 
II. k   for  a  list  of  error  codes). 

8.  REGREL  identifies  six  bytes  which  provide  the  register  relocation 
controls  (see  section  III.B). 
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ERROR  NAME 

ERROR  NUMBER 

BADCMD 

1 

BADDIR 

2 

BADNAM 

k 

NOTFND 

6 

INUSE 

10 

NOROOM 

12 

NOSUCH 

Ik 

NOTCLS 

16 

NOTAVL 

20 

NOTOFN 

22 

PRVIOL 

2k 

EOF 

26 

ABORT 

30 

DATERR 

32 

KNGDEV 

3k 

NOLOAD 

35 

CKSMER 

36 

OUTRNG 

37 

MEANING 
Invalid  command 
Directory  screwed  up 
Badly  formed  file  name 
File  not  found 
File  of  same  name  is  in  use 
Directory  is  full  or  disk  is  full 
File  or  UFD  does  not  exist 
Can't  open  already  open  channel 
Device  not  available  to  user 
Trying  to  operate  on  unopened  channel 
Protection  violation 
End  of  file  on  read/write 
Operation  aborted 
Data  error  on  device 
Hung  device  for  job 

No  load  address  specified  on  object  file 
Checksum  error  in  loader 
Address  requested  out  of  user  area 


Figure  II. k     FIP  or  i/O  Error  Codes 
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9«   COMWRD  identifies  four  words  which  are  reserved  for  communi cations 
between  the  system  and  the  user  job.   These  words  presently  have 
no  designated  meaning  in  the  system  and  may  be  used  at  will  by  the 
user  job. 
10.   USRFLG  is  a  communication  word  in  which  the  system  sets  flags  to 
indicate  that  the  user  has  typed  a  control  character  which  should 
be  meaningful  to  the  user  job  (see  section  VII. B) . 
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III.   Code  Description 

A.  Dynamic  Relocatability 

Since  the  PDP-11  has  no  relocation  hardware  and  ETS  intends  to  be 
a  timesharing  monitor,  the  code  in  ETS  must  be  relocatable.   This 
means  that  ETS  must  be  able  to  stop  the  execution  of  the  user  job 
at  any  time  in  order  to  swap  it  out  to  allow  another  process  to 
run.  When  ETS  determines  a  job  is  to  be  swapped  in  again  from  disk, 
it  does  not  necessarily  return  the  job  to  the  same  position  in 
memory.  A  job  does,  however,  always  remain  in  a  single  contiguous 
block  so  relative  distances  within  the  job  itself  do  not  change. 

1.  Dynamic  relocatability  requires  the  use  of  strictly  relative 
addressing  modes  with  the  user's  program  variables. 

2.  When  referencing  system  variables  such  as  REGREL  or  USRFLG  the 
user  must  use  strictly  absolute  addressing  (i.e.,  INCB  @#REGREL) . 

3»  With  the  exceptions  noted  here,  the  user  must  not  develop 
absolute  addresses  pointing  anywhere  in  the  user  area. 

k.     ETS  does  provide  limited  ability  to  develop  absolute  pointers 

into  the  user  area.   The  user  job  may  inform  ETS  of  its  intentions 
to  place  an  absolute  address  in  a  register  or  it  may  place 
absolute  addresses  on  the  stack  or  it  may  place  them  in  reserved 
pointers  in  system  area  (RELPTR). 

B.  Register  Relocatability 

1.  When  a  user  wishes  to  place  an  absolute  pointer  in  a  register  he 
may  tell  ETS  of  his  intentions  by  putting  a  non-zero  quantity  in 
the  register  relocation  byte  (REGREL)  corresponding  to  that 
register.   Six  REGREL  bytes  are  assigned  to  the  registers  RO  to 
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R5  in  order  beginning  with  RO.  Any  non-zero  quantity  in  a 
register  relocation  byte  indicates  that  a  user  may  have  absolute 
pointers  in  the  corresponding  register  (see  example  III.l). 

2.   Conditional  Relocation 

When  ETS  finds  a  non-zero  REGREL  byte,  it  assumes  that  the 
corresponding  register  may  contain  an  absolute  pointer  into  the 
user  area.  However,  should  ETS  need  to  relocate  that  register, 
it  will  check  the  contents  of  the  register,  to  see  if  it  actually 
contains  a  value  which  would  be  a  valid  pointer  into  user  area. 
If  it  does  not  contain  a  possible  absolute  address  for  the  user 
(a  value  which  lies  between  30000o  and  60000n),  ETS  will  not 
relocate  the  register. 

3«   Conditional  relocation  allows  the  user  to  conveniently  construct 
absolute  pointers  in  registers  without  having  critical  segments 
of  code  (code  which  must  not  be  interrupted  during  execution). 
The  following  example  is  not  a  critical  section  because  of 
conditional  relocation: 

INCB  @^REGREL+1    ;Mark  Rl  as  absolute 
MOV   #K-.-6,  Rl    ;Load  offset  to  desired  variable 
ADD   PC,  Rl        ;Make  it  an  absolute  pointer 
If  the  job  is  interrupted  and  swapped  between  the  MOV  and  ADD 
instructions,  it  will  try  to  relocate  Rl  but  will  not  find  a 
value  in  Rl  which  does  not  point  to  user  core  (X  is  a  local  variable) 
and  will  not  change  it.  Without  conditional  relocation,  the 
system  would  modify  Rl  which,  at  the  time  of  the  interrupt, 
contained  a  relative  offset  rather  than  an  absolute  pointer. 
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REGREL  -     xxx  ;Address  of  register  relocation 

;Byte  zero 


INCB     @t^IEGREL+3        ;Register  3  is  to  be  relocated 
INCB     @^REGREL+5        ;Register  5  is  to  be  relocated 


Example  III.l  Marking  Registers  Which  May  Contain 
Absolute  Pointers 


15 

k-.      The  stack  in  ETS  is  a  conditionally  relocated  area  (see  III.D), 
and  consequently  the  user  must  be  careful  about  saving  registers 
on  the  stack.   In  general,  registers  which  are  relocatable  may 
be  placed  on  the  stack  and  registers  which  contain  arbitrary 
data  should  not  be  pushed  on  the  stack. 

C.  COMWRD  and  RELPTR 

1.  There  are  four  reserved  words,  beginning  at  COMWRD,  in  the  system 
area  which  have  been  set  aside  as  communication  words  between  the 
system  and  the  user.  None  of  these  four  words  are  presently  in 
use;  hence,  the  user  may  store  anything  he  wishes  in  this  area. 

2.  There  is  an  additional  communication  word  by  the  name  of  USRFLG 
whose  usage  has  already  been  defined  (see  section  II.C.10). 

3.  There  are  seven  words  beginning  at  RELPTR  which  are  kept  as 
automatically  relocated  user  offsets.  Each  of  these  seven  words 
is  changed  by  an  amount  equal  to  the  distance  which  a  user  is 
moved  anytime  the  user  is  swapped.   Thus,  the  user  may  construct 
an  offset  to  an  absolute  pointer  which  does  not  point  directly 
into  user  core  and  still  have  the  system  relocate  it  each  time 
he  is  moved.  When  a  user  job  begins  execution  each  of  these 
seven  "relative  pointers"  will  point  absolutely  to  the  first 
location  in  the  user  area.   Therefore,  the  user  does  not  need  to 
construct  a  program  counter  relative  offset  in  these  pointers. 
He  may  simply  add  the  offset  from  the  beginning  of  his 

own  area  to  the  present  contents  of  the  pointer  and  construct 
his  absolute  pointer  (see  example  III. 2). 

D.  Stack  Conventions 

1.   The  user  stack  is  also  treated  as  a  conditionally  relocated  area. 
Each  time  a  user's  job  is  swapped  out  and  brought  in  at  a  different 
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RELPTR 

=         XXX 

PTRONE 

RELPTR 

PTRTWO 

RELPTR+2 

; Address   of  relocating  pointers 


ADD       #XRB,@#PTRONE  ;  PTRONE  now  contains  an  absolute 

jpointer  to  XRB  -  the  system  initially  loads 
; PTRONE  "with  the  user  job   origin 


LNCB    @#REGREL+1  ;Mark  Rl  as  absolute 

MOV       @#PTR0NE,R1  ;Pick  up  pointer  in  Rl 


Example  III. 2     Establishing  and  Referencing  Absolute 
Locations  using  RELPTR 


IT 

location  the  system  examines  all  words  "between  the  current  top  of 
stack  and  the  stack  base,  and  relocates  any  of  those  which  point 
absolutely  into  the  user  area.  Note  that  the  JSR  instruction  and 
the  processor  trap  instructions  also  cause  the  current  value  of 
the  program  counter  to  be  pushed  onto  the  stack.   The  trap 
instructions  also  cause  the  processor  status  word  to  be  pushed 
onto  the  stack.   Since  the  stack  is  a  conditionally  relocated 
area  the  system  will  modify  the  program  counter  values  when 
necessary;  however,  the  processor  status  word  is  not  a  possible 
pointer  into  the  user  area  and  the  system  will  not  change  it. 

2.  When  a  user  gob  begins  execution  it  has  the  minimal  stack  size 

of  ^00n  bytes.   The  user  may  increase  this  if  need  be,  however, 

he  may  not  decrease  it.  When  calculating  the  amount  of  stack 

necessary  for  his  job,  the  user  should  determine  the  maximum 

number  of  bytes  that  he  might  need  at  any  time  and  then  add  200o 

o 

bytes  to  that  for  system  use  and  for  a  protection  buffer.  Notice 
that  there  is  no  form  of  protection  for  user  stack  overflow.   Thus, 
care  must  be  taken  to  insure  that  no  user  stack  overflows  occur. 

3.  Should  a  user  need  to  increase  his  stack  size,  he  simply  loads  his 
desired  stack  size  into  a  system  variable  called  STKBAS.   (He  cannot 
just  add  an  increment.)   The  user  can  use  this  facility  should 
he  need  to  create  a  table  of  pointers  into  his  user  area.   By 
telling  the  system  that  he  has  increased  his  stack  size  but  not 
actually  doing  so,  the  user  can  create  a  table  which  will  be 
conditionally  relocated.   If  he  loads  the  absolute  values  of  the 
pointers  he  wants  into  this  table,  he  has  a  table  of  relocated 
values  which  may  be  used  as  a  dispatch  table  (see  example  III. 3). 
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STKBAS  =  xxx 
JOBORG  =  xxx 
TBLSIZ  =  16 


;Address  of  user  stack  size  variable 

; System  pointer  to  beginning  of  user  job 

;Our  jump  table  will  have  16  entries 


MOV  #TBLSIZ+TBLSIZ-t400,@#STKBAS 

MOV  #TBLSIZ,  RO 

ADD  #1-01,  @t^EGREL+2 

MOV  @#J0B0RG,  R2 

MOV  R2,  R3 

ADD  #100,  R2 

Bl:    MOV  Rj5,  (R2)  + 

DEC  RO 

BGT  Bl 

ADD  #^00,  R3 

ADD  #3UB1,  (B5)+ 

ADD  $SUB2,  (R3)+ 


Set  our  new  "stack"  size 

Set  up  TBLSIZ  entries 

Mark  R2  &  R3  as  absolute  address  regs, 

Pick  up  start  of  our  job 

and  replicate 

Point  just  above  stack  base 

Fill  table  with  our  own  job  origin 

Count  this  entry 

And  get  them  all 

Now  use  Rj5  to  finish  construction 

of  table 

Abs.  jump  address  to  SUBl 

Abs.  jump  address  to  SUB2 


ADD  #SUBl6  (R3)+ 


;Abs.  jump  address  to  SUB16 


Example  III. 3 


Construction  of  a  Dispatch  Table 
Containing  Absolute  Addresses 
at  Base  of  Stack 
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km      The  user  should  be  careful  about  using  instructions  of  the  form 
JSR  R5, X  where  R5  may  not  be  a  relocatable  register  since  the 
system  pushes  the  contents  of  the  register  onto  the  stack.   If  R5 
is  an  absolute  piece  of  data  which  looks  like  a  pointer  into  the 
user  area  the  system  will  change  the  data  in  R5  if  the  user  is 
swapped.  A  useful  technique  for  the  user  who  needs  a  stack  which 
may  contain  arbitrary  data  is  to  create  a  separate  data  stack 
below  the  user's  real  stack  and  use  another  register  such  as  R5 
as  a  stack  pointer.  Note  that  R5  must  be  indicated  as  a  relocatable 
register.  Also  note  that  R5  does  not  behave  exactly  like  SP  in 
doing  byte  operations  in  auto  increment  and  auto  decrement  mode. 
E.   Processor  Status  Word  Manipulation 

1.   In  general  the  user  should  avoid  modifying  the  processor  priority. 
However,  he  may  examine  and  modify  the  condition  codes  in  the 
processor  status  word  at  will.   There  may  be  times  when  it  is 
necessary  for  the  user  to  execute  short  sections  of  code  without 
interruption.   This  may  be  done  by  running  at  system  priority 
seven.   The  user  may  either  set  the  priority  to  seven  in  the 
processor  status  word  himself  or  he  may  use  system  routines  to 
do  so.   The  system  provides  two  routines:   IOF  and  ION  to  raise 
the  priority  to  seven  and  lower  it  to  its  original  priority 
respectively.   These  routines  are  called  by  JSR  PC,  @#IOF  and 
JSR  PC,  @#ION  respectively.   These  two  routines  must  be  executed 
as  a  pair  and  the  user  must  take  caution  to  avoid  executing  two 
consecutive  IOF  calls.   (This  will  cause  the  system  to  be  locked 
at  priority  seven.) 
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2.  In  general  the  user  does  not  need  to  run  at  priority  seven;  however, 
he  may  wish  to  execute  sections  of  code  without  being  swapped  out. 
He  can  do  this  by  running  at  system  priority  three.  This  allows 
the  system  to  perform  normal  I/O  but  will  not  allow  the  system  to 
switch  to  another  job.   The  user  need  not  worry  about  informing 
the  system  about  absolute  pointers  which  exist  only  during  PR3 
execution,  as  the  user  cannot  be  swapped. 

a.  Like  the  use  of  priority  seven,  the  use  of  priority  three 
should  be  restricted  to  short  segments  of  code.  Normally  50 
to  100  instructions  or  less. 

b.  Should  the  user  need  to  execute  large  segments  of  code  at 
priority  three,  he  must  inform  the  system  when  it  is  alright 
for  him  to  be  swapped.   In  general,  if  more  than  1-2$  of  a 
user's  code  is  to  be  executed  at  priority  three  he  should 
attempt  to  inform  the  system  each  time  he  returns  to  priority  ' 
0  that  he  is  available  for  swapping.   This  is  done  by  simply 
executing  an  EMT  .BREAK.   If  the  system  has  another  job 
requesting  the  use  of  the  CPU  it  will  switch  to  that  job;  if 
not,  it  will  return  immediately  to  the  user  job. 

c.  Even  though  the  user  does  not  intend  to  execute  his  code  at 
priority  3>  he  may  cause  the  same  effect  if  he  does  a  great 
deal  of  disk  i/o.  When  the  user  executes  a  disk  i/o  transfer, 
he  is  locked  into  his  core.  While  the  processor  may  switch 
tasks  if  there  is  another  runnable  task  which  is  core  resident, 
the  job  may  not  be  swapped  out.   Consequently,  programs  doing 
many  disk  transfers  should  execute  an  EMT  .BREAK  periodically 
(~3-5  transfers)  to  allow  the  system  to  swap  him  out. 


21 

F.  System  Buffer  Allocation 

1.  Some  other  operations  require  the  use  of  buffers  which  remain  in 
core  even  though  the  user  may  he  swapped  out.   For  this  purpose 
the  system  maintains  a  pool  of  approximately  100  buffers  which  may 
be  allocated  to  the  user  for  short  periods  of  time.  All  system 
buffers  are  20n  words  in  length  and  are  allocated  by  calls  to 

the  system  buffer  allocation  routine  (see  section  IV. H).  All 
buffers  are  allocated  on  40n  address  boundaries. 

2.  When  the  system  allocates  a  buffer  to  the  user  job,  it  loses  all 
record  of  that  buffer  and  depends  on  the  user  to  return  it  when 
he  has  completed  his  work  with  it.   Since  it  is  possible  for  the 
student  to  cause  the  user  job  to  be  killed  by  typing  a  CNTL  C 
(tC),  users  must  be  careful  about  the  allocation  and  deallocation 
of  system  buffers.   Special  care  should  be  taken  to  see  that  user 
jobs  do  not  have  system  buffers  allocated  during  I/O  operations. 

G.  Anchor  Mode 

If  for  some  reason  it  is  impossible  or  impractical  to  write  code 
which  is  dynamically  relocatable,  a  user  may  specify  that  his  code  be 
run  in  'Anchor  Mode'  which  means  that  the  system  will  swap  him  back 
to  the  same  place  each  time  he  is  brought  into  core. 

In  order  to  run  in  Anchor  Mode,  the  user  must  first  execute  an 
EMT  .ANCHR  (see  section  VI. A)  and  then  cause  himself  to  be  swapped  out 
so  the  system  can  position  him  (see  example  III.lj-). 

When  a  user  no  longer  requires  that  he  be  anchored  he  should 
execute  a  .HOIST  to  release  himself.   Since  the  use  of  anchor  mode 
works  quite  a  hardship  on  the  system,  it  should  be  avoided  whenever 
possible. 


22 


;This  routine  will  anchor  a  2K  program  at  30000. 
; Since  the  program  may  have  already  been  loaded 
; elsewhere  it  is  necessary  to  force  the  program 
;to  be  swapped  to  the  proper  location.   This  can 
;be  done  by  increasing  the  size  of  the  program 
;and  then  decreasing  it  again. 


.ANCHR  =  lOlj-112 
.CORE  =  104056 
HEGIN:  MOV  #30000,  Rl 
.ANCHR 
MOV  #2,R0 
.CORE 
MOV  #3,R0 
.CORE 
MOV  #2,R0 
.CORE 


;Anchor  at  30000 

> 

;We  should  be  at  size  two. 

;Make  sure  we  are. 

;Now  increase  to  size  three 

; forcing  a  swap. 

;Now  decrease  to  size 

;two  again. 


Example  III. h     Anchoring  a  Program 
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H.   Named  Code 

In  order  to  allow  the  system  to  provide  special  assistance  to 
selected  programs,  it  accepts  a  name  for  a  program  which  it  may  use 
to  identify  the  type  of  job  in  progress.  When  a  program  begins 
execution,  it  may  execute  an  EMT  .NAME  (see  section  VI.  ).  When 
the  program  executes  a  .EXIT,  the  name  will  be  removed.   This  facility 
is  useful  when  the  system  must  service  a  user  who  may  have  terminated 
execution.   By  checking  the  existence  of  the  proper  name,  the  system 
can  avoid  damaging  or  unnecessarily  servicing  users. 

It  is  necessary  that  any  new  names  be  unique  among  the  names 
known  to  the  system.  However,  this  is  not  a  hardship  since  names 
are  useful  only  when  special  service  routines  are  included  in  the 
system  and  the  names  may  be  selected  when  the  routines  are  written. 
Currently  only  the  name  DTAD0=1  is  in  use  and  is  reserved  for 
routines  using  DECtape  service. 
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IV.      File  Handling 

A.  File  Operation 

All  operations  which  concern  the  handling  of  data  which  is  stored  on 
the  disk  are  file  operations.   In  addition,  ETS  supports  a  number  of 
non-resident  functions  which  are  also  treated  as  file  operations 
though  they  may  actually  have  little  or  nothing  to  do  with  the  filing 
system.   The  ETS  filing  system  consists  of  a  core-resident  and  a 
disk -resident  portion.  On  disk  are  stored  a  number  of  special 
functions  which  may  be  called  into  core  when  needed.  All  file 
operations  are  carried  out  by  allocating  a  system  buffer,  called  a 
FIRQB,  and  placing  the  number  of  the  requested  function  as  well  as 
any  necessary  parameters  in  this  buffer.   The  user  then  places  the 
address  of  the  buffer  in  F&-  and  executes  an  EMT  CALFIP. 

B.  File  Request  Queue  Block  (FIRQB) 

1.  When  performing  file  operations,  the  user  must  request  a  system 
buffer  and  load  it  with  the  proper  parameters  (see  figure  IV. l). 
This  FIRQB  requires  the  user's  job  number,  FQJOB,  and  a  function 
code,  FQFUN  (the  system  provides  a  routine  to  allocate  the  buffer 
and  load  these  two  words  -  see  section  IX. C).   In  addition,  the 
user  must  supply  any  special  parameters  relative  to  the  process 
he  is  using  (see  section  IV.C).  Generally,  the  system  will  return 
the  FIRQB  to  the  user  on  completion  of  an  operation.   The  user  may 
get  any  results  which  were  returned  in  the  FIRQB  and  should  then 
return  the  FIRQB  to  the  system.   See  example  IV. 1. 

C.  Available  File  Operations 

1.  EXTFQ  is  a  routine  to  extend  the  length  of  a  disk  file.   The  user 
loads  in  FQFIL  the  channel  index  of  the  file  which  he  wishes 
extended.   In  FQSIZ  he  supplies  the  number  of  256-.  _  word  blocks 
to  extend  the  file.  If  the  disk  is  full,  or  no  disk  blocks  remain, 
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Purpose 

Queue  word  for  chaining  requests 

Job  #  issuing  request  (*2) 

Function  requested 

Channel  index 

Error  or  message  #  requested  from  file 

Size  of  file  to  be  created  or  number 
of  segments  to  extend  file 

New  protection  code 

Project -programmer  number  of  UFD  desired 

FILENAME. EXT  in  RAD50 

Project -programmer  number  of  second  UFD 

FILENAME. EXT  of  second  file 

Number  of  absolute  loader  blocks  loaded 

Number  of  check  sum  errors  encountered. 

Offset  from  beginning  of  user  area  to 
"relative  0"  of  file  to  be  loaded 

EAD50  device  name 

RAJJ50  device  number 

Length  of  string  to  be  parsed 

Absolute  pointer  to  buffer  containing 
source  string  to  be  parsed—string  is 
in  chained  set  of  system  buffers  for 
SWIFQ 

(Note  that  FQJOB  and  FQFUN  must  always  be  supplied — all  other  parameters  need  to 

be  supplied  when  actually  needed. ) 

Figure  IV. 1  FIRQB  Structure 


Name 

Value 

Length  (bytes) 

FQQQ 

0 

2 

FQJOB 

2 

1 

FQFUN 

3 

1 

FQFIL 

k 

1 

FQERNO 

k 

2 

FQSIZ 

5 

1 

FQPROT 

5 

1 

FQPPN1 

6 

2 

FQNAM1 

10 

6 

FQPPN2 

16 

2 

FQNAM2 

20 

6 

FQBLCK 

22 

2 

FQCKSM 

2h 

2 

FQSTRT 

26 

2 

FQDEV 

30 

2 

FQDEVN 

32 

2 

FQLEN 

3h 

2 

FQPTR 

36 

2 

BUFFER 

=   k 

GETSML 

=   200 

RETSML 

=   0 

FQJOB  = 

2 

FQFUN  = 

3 

FQFIL  a 

k 

FQLEN  = 

3h 

FQPTR  = 

36 

OPNFQ  = 

10 

CSIFQ  = 

1+6 

CALFIP 

=  101+050 

REGREL 

=    XX 

JOBORG 

=    XX 

IOSTS  = 

XX 

JOB  =  xx 

• 

STRING: 

• 
• 

.ASCII 

/fileab.ext/ 

STREND: 

.BYTE   0 

CHNNDX: 

.BYTE   k 
.EVEN 

• 
• 

INCB 

@#REGREL+0 

BUFFER 

GETSML 

MOV 

#STRING,RO 

AIJD 

@#JOBORG,RO 

MOVB 

(R0)+,  (Rl+)  + 

BNE 

.-2 

BIC 

#37,  R^ 

MOV 

Bk,  -(SP) 

BUFFER 

GETSML 

MOV    ' 

(sp)+,fqptr(rV) 

MOV 

#STREND-STRING,  FQLEN  (Rl+) 

MOVB 

#csifq,fqeun(ri+) 

MOVB 

@#job,fqjob(ri+) 

CALFIP 

MOV 

@#I0STS,R1 

MOV 

FQPTR  (Rif),-(SP) 

TST 

(HI), 

BNE 

ERROR 

MOVB 

CHNNDX,  FQFIL  (Rl+) 

MOVB 

#opnfq,fqfun(ri+) 

CALFIP 

TST 

(HI) 

BEQ 

OKAY 

ERROR: 

BUFFER 
RETSML 

OKAY: 

MOV 

BUFFER 

RETSML 

(SP)+,Rl+ 
Example  IV. 1     Routine  ' 
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;Name  of  file  to  be  opened 
; Channel  index  -  even  # 


RO  is  relocatable 

Request  a  16  word  buffer 

Pointed  to  by  ~Rk 

Point  to  file  name  relative  offset 

Make  an  absolute  pointer 

Store  string  in  buffer 

a  byte  at  a  time 

Make  Rl+  point  to  beginning  of  buffer 

Save  Rl+ 

Get  a  FIRQB 

Store  pointer  to  file  string  in  FIRQB 

Store  length  of  file  string 

Load  function  desired 

Load  our  job  index 

Call  the  file  processor 

Get  pointer  to  our  I/O  status 

Save  pointer  to  file  string  buffer 

for  later  return 

Operation  successful? 

No 

Yes  -  load  channel  index  on  which 

file  is  to  be  opened 

Set  open  function 

Call  file  processor  again 

Successful 

Yes  -  FIRQB  was  not  returned 

Failed  -  return  FLRQB 

Get  pointer  to  file  string  buffer 
and  return  it 


into  a  FIRQB  and  Open  the 
File  on  Channel  2 
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an  error  code  12  (NOROOM)  is  returned  in  IOSTS. 

2.  DELFQ  is  a  routine  to  delete  an  open  file.   The  user  supplies  the 
channel  index  of  the  file  in  FQFIL.   The  user  must  be  write  enabled 
on  the  file  in  order  to  delete  it. 

3.  CLSFQ  is  a  routine  to  close  an  open  file.   The  user  supplies  in 
FQFIL  the  channel  index  of  the  file  he  desires  closed. 

h.      OPENFQ  is  a  routine  to  open  a  file.   The  user  must  supply  in  FQFIL 
a  presently  unused  channel  index.   In  FQNAM1  he  must  supply  a  three 
word  file  name  which  is  packed  RAD50.   If  the  user  wishes  to  open 
a  file  which  belongs  to  a  different  project -programmer  number  he 
supplies  the  project -programmer  which  owns  the  file  in  FQPFN1. 
In  order  to  open  a  file  a  user  must  be  either  read  enabled,  write 
enabled  or  the  owner  of  the  file.   If  the  open  operation  is 
successful  the  FIRQB  will  not  be  returned  to  the  user. 

5.  CREFQ  is  a  routine  to  create  a  file.   The  user  supplies  in  FQNAM1 
a  file  name  of  the  form  FILNAM.EXT  packed  RAD50.   In  FQSIZ  he 
specifies  the  length  of  the  file  which  he  wants  created.  A  length 
of  zero  or  one  is  created  as  a  file  of  length  one  block.   If  a 
file  of  this  name  already  exists  in  the  user's  UFD  and  the  user  is 
write  enabled  on  that  file,  the  system  will  delete  that  file  and 
recreate  it  at  its  new  length. 

6.  RENFQ  is  a  routine  to  rename  an  existing  file.   The  user  supplies 
in  FQNAM1  the  name  of  the  file  which  he  wishes  to  rename.  He 
supplies  in  FQNAM2  the  new  name  of  the  file.   The  user  must  be 
write  enabled  on  a  file  before  he  can  change  its  name.   If  the  file 
does  not  belong  to  the  user's  project -programmer  number  he  specifies 
a  project -programmer  number  of  the  file  in  both  FQPPN1  and  FQPFN2. 
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7«   BYEFQ  is  a  routine  to  log  out  a  user  from  the  system.  No  parameters 
other  than  the  user's  job  number  need  be  supplied.  Before  logging 
out  a  user,  the  system  will  close  all  his  open  files.  BYEFQ  does 
not  return! ! 

8.  DIRFQ  is  a  routine  to  return  directory  information  on  a  file  entry. 
The  user  supplies  in  FQPPN1  a  project-programmer  number  of  the 
directory  with  which  he  is  concerned.  All  files  in  a  given  directory 
(UFD)  are  numbered  sequentially  beginning  with  zero.   The  user 
supplies  in  FQFIL  the  number  (this  is  not  a  channel  index)  of  the 
file  on  which  he  wishes  information.   If  there  exists  a  file 
corresponding  to  the  number  specified,  the  system  will  return  the 
name  of  the  file  in  the  three  words  beginning  at  FQNAML.   The 
system  will  return  the  protection  code  associated  with  the  file 

in  FQPEN2.   It  will  return  the  date  of  the  last  access  at  FQNAM2, 
which  will  be  immediately  followed  by  the  size  of  the  file  (the 
number  of  256  ~  word  blocks),  followed  by  the  creation  date  of  the 
file,  followed  by  the  time  the  file  was  created. 

9.  FROFQ  is  a  routine  to  change  the  protection  code  associated  with  the 
file.   The  user  supplies  in  FQFIL  the  channel  index  on  which  the 
file  is  open.  He  supplies  in  FQPROT  the  new  protection  code  to  be 
assigned  to  the  file.   The  user  may  not  change  the  protection  of  a 
file  unless  he  is  either  write  enabled  or  the  owner  of  the  file. 

10.  EKRFQ  is  a  routine  to  return  an  error  message  from  the  system  error 
file.  The  user  supplies  in  FQEKNO  the  error  number  which  he  would 
like  to  have  returned.   On  return  the  system  will  pack  the  error 
message  into  the  FIRQB  beginning  at  FQKRNO. 
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11.  LOAFQ,  is  the  system  relocating  loader.   The  user  supplies  in  FQFIL 
the  channel  index  of  the  file  to  be  loaded.  He  supplies  in  FQSTRT 
an  offset  from  the  beginning  of  the  user  area  to  the  zero  of  the 
load  file  (a  zero  here  causes  the  file  to  be  loaded  "with  the  load 
"0"  corresponding  to  the  beginning  of  the  user  area).   On  return 
the  system  supplies  in  FQBLCK  the  number  of  loader  blocks  loaded. 
This  includes  the  six  word  start  block.   The  system  also  returns  in 
FQCKSM  the  number  of  checksum  errors  occurring  during  the  load. 

12.  RSTFQ,  is  a  routine  to  close  all  i/o  channels  except  channel  zero. 
The  user  needs  no  additional  parameters. 

13.  CSIFQ,  is  a  routine  to  parse  DEV :  FILE.  EXT  [X,X] .   The  user  must 
allocate  a  system  buffer  and  pack  the  string  to  be  parsed  into  the 
buffer.  He  then  places  the  address  of  this  buffer  at  FQPTR  and 
places  the  length  of  the  string  to  be  parsed  at  FQLEN.   The  system 
returns  the  RAD50  pack  of  any  device  name  at  FQDEV.   The  RAD50  pack 
of  any  device  number  is  returned  at  FQftEVN.   Independent  of  the 
presence  or  absence  of  a  device  name  and  device  number,  the  system 
packs  a  string  of  up  to  six  characters  as  a  file  name.   They  are 
packed  RAD50  and  placed  beginning  at  FQNAM1.   If  there  are  less  than 
six  characters,  the  name  is  considered  to  be  extended  on  the  right 
with  blanks  to  form  a  six  character  name.  A  file  name  may  be 
followed  by  a  three  character  extension  to  indicate  its  type.   The 
extension  is  packed  and  stored  at  FQNAMl+ij-.   It  too  is  extended 
with  blanks.  Additionally,  the  user  may  specify  a  project-programmer 
number  by  enclosing  it  in  square  brackets  ([k, 5])«   The  two  numbers 
are  considered  as  octal  and  must  be  separated  by  a  comma.   They  will 
be  stored  in  the  two  bytes  of  FQRFN1 — the  first  digit  goes  into  the 

high  order  byte. 
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Ik-.     SWIFQ,  is  a  routine  to  parse  a  list  of  switches.  The  user  must  pack 
the  list  of  switches  into  system  buffers  which  may  be  chained 
together.  He  supplies  a  pointer  to  the  first  buffer  at  FQPTR.   The 
first  word  of  each  buffer  is  then  a  pointer  to  the  next  buffer  in 
the  chain.  The  last  buffer  in  the  chain  has  a  zero  in  its  first 
word.  The  user  supplies  the  length  of  the  string  in  FQLEN.  See 
figure  IV. 2  for  a  description  of  a  possible  switch  list.  On  return, 
the  system  returns  the  FIRQB  in  addition  to  the  first  buffer  in  the 
chain.  All  other  buffers  are  returned  to  the  system  buffer  pool. 
The  buffer  pointed  to  by  FQPTR  will  contain  the  parse  information 
for  the  switch  list.  Each  of  the  possible  switches  is  associated 
with  two  words  in  the  buffer  (beginning  with  the  third  word  of  the 
buffer,  in  order,  as  given  in  <switch>  in  figure  TV.2).   In 
the  low  order  byte  of  the  first  word  of  any  switch  which  occurs  is 
stored  an  octal  constant  or  the  length  of  an  arbitrary  string  which 
was  the  last  parameter  to  the  switch.  Bits  8  through  Ik   indicate 
the  presence  of  the  parameters  numbered  1  through  7  (in  order  as 
given  by  <parm>  in  figure  IV.2).  Bit  15  of  the  first  word  is  set 
to  indicate  that  this  particular  switch  occurred  in  the  list  of 
switches.  The  second  word  of  the  switch  list  is  a  pointer,  relative 
to  the  beginning  of  the  string,  to  the  beginning  of  an  ASCII  string 
which  was  a  parameter  to  that  switch.  In  case  of  an  error  return 
all  buffers  except  the  FIRQB  will  be  returned  to  the  system. 
Figure  IV. 3  is  a  diagram  of  the  buffer  returned  for  a  sample  switch 
string. 
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<switch  list> 
<switch  string> 
<switch> 
<parm  llst> 

<parm  string> 

<parm> 

<octal  string> 

<A.SCII  string> 


<switch  string>|<switch  string>;<switch  list> 
<switch>j<switch>:<parm  list> 

op|cl|ee|pr|de|s6|s7 

<parm  string> | <parm  string>:<octal  string>| 
<parm  string>:<ASCII   string> 
<parm>  |  <parm> :  <parm  s  tr  ing"> 

cn|ee|p3|p1+|p5|p6|p7 

<string  of  ASCII  characters  which  represent 
octal  digits> 

<string  of  ASCII  characters  which  cannot  be  an 
octal  string> 


Figure  IV. 2  The   BNF  Definition  of  a  Switch  List 
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129  is  not  a  valid  octal  constant,  hence  it  is  returned  as 
a  string  length 


Figure  IV. 3  The  Buffer  Returned  on  Parsing  a  Switch  List 
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15-   FNDFQ,  is  a  routine  to  check  if  a  given  file  or  device  is  open  and 

if  so  to  return  the  channel  index  on  which  it  is  open.   It  is  called 
by  placing  the  name  of  the  file  at  FQNAM1  or  the  device  name  at 
FQDEV  with  any  device  number  at  FQfEW.   On  return  FQFIL  will  contain 
the  channel  index  of  the  channel  on  which  the  given  file  or  device 
is  open.   If  the  file  or  device  is  not  open  it  will  return  an  error 
lk-   (NOSUCH).   If  the  file  or  device  does  not  exist  it  returns  an 
error  22  (NOTOPN). 
D.  Error  Return 

When  a  specified  file  request  fails  to  function  properly  it  will  return 
in  the  second  word  of  the  user's  job  data  block  an  error  code.   The  system 
variable  IOSTS  contains  a  pointer  to  this  i/O  status  word.   Figure  II. 3 
contains  a  list  of  possible  error  codes  and  an  indication  of  their 
meaning . 


V.   Input -Output 

A.  General  Principles 

1.  All  device  i/O  in  ETS  is  controlled  by  constructing  a  transfer 
control  block  (XRB)  which  contains  all  the  necessary  parameters 
for  the  desired  operations  (see  figure  V.l).   There  are  four  basic 
items  which  must  be  supplied: 

a.  Buffer  Address.   The  user  places  in  the  XRB  in  two  places 
(XRPTR  and  XRLOC)  the  address  of  the  buffer  to  be  used  in  the 
transfer.  The  address  is  in  the  form  of  the  relative  distance 
from  the  buffer  to  the  XRB  (#XRB-BUF).   The  buffer  must  be  in 
the  user  area  proper. 

b.  Transfer  Length.   On  a  read  operation,  the  user  places  a  zero 
in  XRBC  and  the  maximum  length  of  transfer  (in  bytes)  in  XRLEN. 
On  return,  the  system  will  put  the  number  of  bytes  actually 
transferred  in  XRBC.  On  a  write  operation,  the  user  places 
the  actual  write  count  in  XRBC. 

c.  Channel.  All  read/write  operations  must  take  place  to  a 
file/device  which  the  user  has  successfully  opened  (channel 
zero  is  automatically  open).   The  user  places  the  channel  index 
in  XRCI.   Before  allowing  the  operations  to  proceed,  the  system 
checks  the  protection  associated  with  a  channel  and  aborts  the 
operation  if  necessary. 

d.  Parameters.   Reading  from  the  card  reader  requires  that  the  user 
supply  parameters  to  allow  the  service  routine  to  perform  the 
proper  character  translation.  Parameters  are  supplies  in  XRPAR 
and  XRPAR2  (see  V.B.3). 
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R3  (Point) 


•z» 


XRB 


(Lnk) 
(Rel) 
(Len) 
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(Parm  1) 


(Parm  2) 


BUF 


Point   = 
Lnk 
Rel 
Len 
Tran 
Chnnl 
Parm  1  = 
Parm  2  = 


Relative  distance  from  start  of  job  to  XRB 

Monitor  link  word 

Relative  distance  (XRB-BUF)  from  XRB  to  i/O  buffer 

Maximum  length  of  i/O  buffer 

Actual  transfer  count 

i/O  channel  for  operation 

Parameter  word 

Parameter  word 


Figure  V.l  Transfer  Control  Block  Structure 
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2.  Once  the  user  has  set  up  his  XRB,  he  places  its  relative  address  in 
R3  (distance  from  user  "0"  to  the  XRB)  and  executes  EMT  52  (.READ) 
or  EMT  5^  (.WRITE). 

3-  When  doing  i/O  to  a  device  other  than  disk,  it  is  possible  that  all 
data  is  not  immediately  available;  hence,  the  system  vd.ll  swap  the 
user  out  of  core  to  await  physical  i/O.   This  is  not  true  for  disk 
operations. 
B.   i/O  to  a  Serial  Device 

1.  Line  -  Block  Oriented  Read 

Normally,  on  read  operations,  the  system  will  attempt  to  supply  the 
maximum  possible  number  of  characters,  with  two  exceptions. 

a.  Any  read  operation  is  terminated  when  an  EOF  is  encountered  on 
the  source  device. 

b.  Line  oriented  devices  will  terminate  a  read  after  transferring 
a  line  delimiter  (provided  the  delimiter  is  encountered  before 
the  maximum  transfer  is  completed. 

2.  Papertape  Reader  -  Papertape  Punch 

The  papertape  reader  and  papertape  punch  do  strictly  block  oriented 
transfers  of  binary  data.  All  operations  will  terminate  with  either 
the  maximum  transfer  length  fulfilled  or  an  EOF  or  EOM  (End  of  Medium), 
Since  leader  and  trailer  tape  look  like  perfectly  valid  binary  data, 
the  user  must  be  careful  when  he  wants  to  avoid  processing  undesirable 
1  nulls ' . 
3»   Card  Reader 

There  are  two  types  of  transfers  from  the  card  reader: 
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a.  ASCII  Source  Data.   The  user  may  specify  parameters  to  the  card 
reader  driver  which  causes  the  first  n  columns  to  be  ignored, 
or  he  may  ignore  the  last  m  columns,  or  he  may  request  that 
trailing  blanks  be  suppressed,  or  any  combination  of  the 
three.   Figure  V.2  details  the  parameters  and  their  meaning. 

b.  Binary  Data.   The  card  reader  looks  like  the  papertape 
reader  where  the  top  eight  rows  of  the  card  correspond  to 
the  columns  of  a  papertape  (row  5  =  bit  l).   The  card  reader 
will  try  to  fulfill  the  read  request  before  terminating  the 
transfer. 

k.      Line  Printer 

The  line  printer  accepts  block  transfers  on  output.   No  parameters 
are  necessary  where  outputting  to  the  line  printer;  however,  it 
does  do  some  special  processing  on  output  characters  in  order  to 
provide  formatting  ability. 

a.  A  form-feed  (ASCII  code  =  Ik)   is  echoed  as  a  page  eject. 

b.  A  carriage  return  is  ignored. 

c.  A  line  feed  is  echoed  as  a  line  feed  and  a  carriage  return 
(the  hardware  does  this). 

d.  A  tab  (ASCII  code  =  11)  prints  as  spaces  up  to  the  next  eight 
space  boundary  (column  eight  is  the  first  such  boundary). 

e.  Rubouts  (ASCII  code  =  177)  are  ignoredo 

f.  Vertical  tabs  (ASCII  code  =13)  are  ignored. 

g.  All  other  characters  print  as  themselves  if  they  exist  on  the 
print  drum.   If  they  do  not  exist  on  the  drum,  the  hardware 
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XRPAR 
XRPAR2 


L5 

87 

0 

First 

Last 

? 

/ 

■7 

Mode    Suppress 


First    -       logical  first  column  of  card  -1 
Last     -       logical  last  column  on  card 
Mode     =   0  =>EBCDIC 

1  =>binary  data  in  top  eight  rows 
Suppress  -       0  =>suppress  trailing  blanks  if  in  EBCDIC  mode 

1  =>do  not  suppress  trailing  blanks 


Figure  V.2  XRB  Parameters  for  Using  the  Card  Reader 
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ignores  then  causing  the  counted  line  position  to  be  one  greater 
than  the  real  line  position.   (Figure  V.J  is  a  table  of  characters 
on  the  print  drum. ) 
h.   The  maximum  line  length  is  128  characters.  Attempts  to  print 
more  than  this  number  of  characters  will  result  in  the  129th 
character  being  deleted  and  replaced  with  a  line  feed. 
5.   Teletype 

The  teletype  is  a  line  oriented  input  device,  but  a  block  oriented 
output  device.   Because  of  the  use  of  the  teletype  as  a  job  control 
device,  many  input  characters  cause  special  processing  to  occur. 
With  the  exceptions  in  the  special  characters  noted  below,  all 
characters  cause  their  correct  7  bit  ASCII  code  to  be  transferred 
to  the  user  buffer.   On  output,  characters  for  which  there  is  no 
output  character  will  echo  as  nulls. 

a.  A  carriage  return  echoes  as  a  carriage  return,  line  feed  and 
inserts  both  a  carriage  return  and  a  line  feed  into  the  user's 
input  buffer.   The  carriage  return  is  a  delimiting  character 
and  will  cause  the  job  to  be  started  if  it  is  blocked  awaiting 
a  delimiter.   On  output,  a  carriage  return  does  not  echo  a  line 
feed. 

b.  A  line  feed  echoes  as  a  carriage  return,  line  feed  but  inserts 
only  the  line  feed  into  the  user's  buffer.  The  line  feed  is  a 
delimiter.   On  output,  the  line  feed  prints  as  a  line  feed  only. 

c.  CNTL  C  echoes  as  a  tC  and  causes  the  user  job  to  be  aborted. 
The  teletype  buffers  are  flushed.   The  user  will  be  returned  to 
monitor  mode. 
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Figure  V-3  Line  Printer  Character  Set 
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d.  CNTL  B  echoes  as  a  tB  and  causes  the  termination  of  all  echoes 
until  the  next  tB  is  typed.  No  character  is  inserted  into  the 
buffer. 

e.  CNTL  0  echoes  as  atO  and  causes  all  programmed  output  to  be 
discarded  as  well  as  any  input  -which  is  not  a  delimiter.   The 
effect  of  a  tO  is  terminated  when  the  delimiter  is  read  out  of 
the  input  buffer  by  the  user  program. 

f.  CNTL  Q  echoes  as  tQUIT  and  places  a  <CK>  in  the  user  buffer. 
Sets  bit  15  of  USRFLG. 

g.  CNTL  U  echoes  as  a  tU  and  causes  the  user  input  buffer  to  be 
flushed  (throwing  away  the  current  line  of  input). 

h.  CNTL  Z  echoes  as  a  t Z  and  is  given  to  the  user  as  an  EOF  'error'. 
i.  A  CNTL  V  echoes  as  a  tV  and  puts  a  <CR>  in  the  user  input 

buffer;  however,  it  sets  bit  zero  of  USRFLG. 
j.  Altmode  echoes  as  a  $  and  acts  as  a  delimiter.  No  characters 

are  placed  in  the  input  buffer, 
k.  Rubout  operates  in  two  modes: 

(1)  In  tape  mode  (which  is  set  via  an  EMT  .TTAPE)  it  is 
discarded.   Tape  mode  is  for  use  in  reading  from  an  ASR 
paper  tape  reader  and  can  be  terminated  by  an  EMT  .TTRST. 

(2)  In  normal  mode,  it  causes  the  last  character  in  the  input 
buffer  to  be  fetched  and  discarded.  Characters  discarded 
are  echoed  in  reverse  order  between  two  back  slashes. 

1.  A  tab  echoes  as  spaces  up  to  the  next  eight  character  boundary. 

A  tab  (ASCII  code  =  11)  is  inserted  into  the  user  buffer. 
m.  A  vertical  tab  echoes  as  eight  line  feeds  and  inserts  a  vertical 

tab  (ASCII  code  =  13)  into  the  buffer, 
n.  A  form  feed  echoes  as  eight  line  feeds  and  places  a  form  feed 

(ASCII  code  =  Ik)   into  the  buffer. 


142 

Example  V.l  gives  a  sample  program  to  input  a  character  string  from 
a  teletype.  Example  V.2  is  a  sample  message  output  routine. 
File  I/O 

File  operations  involve  all  transfers  to  and  from  the  disk.  All  such 
transfers  involve  exactly  256nn  words.   Files  in  ETS  are  logically 
sequential,  but  they  may  physically  reside  anywhere  on  the  disk.  When 
a  file  is  opened,  a  pointer  (FCWLB)  is  set  up  to  the  first  block  (block 
zero)  in  the  file.  Each  read/write  operation  causes  this  pointer  to  be 
advanced  by  one  block.  Before  reading  or  writing  to/from  a  file,  the 
user  must  open  the  file  (see  section  IV)  on  an  available  channel. 

On  the  disk,  an  EOF  is  generated  anytime  the  user  attempts  to  operate  on 
a  disk  block  which  is  not  a  part  of  that  file.   If  the  operation  was 
read,  an  EOF  indicates  the  end  of  the  data;  however,  if  the  operation 
was  a  write,  the  system  provides  a  function  which  the  user  may  call  to 
extend  the  file  (EXTFQ,  -  section  IV.C.l)  so  that  the  write  operation 
may  be  repeated. 

Although  most  normal  disk  usage  is  of  a  sequential  nature,  ETS  provides 
facilities  so  that  users  may  perform  random  block  access  operations. 
This  requires  that  the  user  know  the  logical  block  number  which  he  wishes 
to  read/write. 

To  select  a  specific  block,  the  user  must  place  the  block  number  desired 
in  the  first  parameter  word  of  the  XRB  and  the  channel  on  which  the  file 
is  open  at  XRCI.  He  then  places  the  relative  address  of  the  XRB  in  Rj5 
and  executes  an  EMT  .FIND.   If  the  request  is  for  a  non-existent  block, 
the  system  will  set  bit  15  of  the  XRPAR  on  return.   In  such  a  case, 
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Reader  is  a  routine  to  read  a  string  from  the  TTY  into 

an  80  character  input  buffer 

Call 

JSR  PC, READER 

RO  relocatable 


Return 


RO  points  absolutely  to  input  string 
R3  contains  byte  count 


READER: 

MOV 

#XRB,R3 

.READ 
MOV 

XRB+6,  R3 

MOV 

#INBUE,R0 

ADD 

@#J0B0RG,  RO 

MOV 

XRB+2,  XRB+10 

CLR 

XRB+6 

RTS 

PC 

XRB: 

.WORD 

0,  INBUE -XRB, 

INBUE: 

.WORD   0 
.=.+120 

r 

;Read  a  string 

; Store  byte  count  in  R3 

;Get  absolute  address  of  INBUE 

;In  2  steps 

;Restore  XRB  pointer 

; Clear  byte  count 

; Return 


; Input  buffer 


Example  V.l  A  Routine  to  Read  a  String  from  the  Teletype 
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MESSAG  is  a  routine  to  output  a  message  on  the  TTY 
Call 

JSR      R5,  MESSAG 
+        MSG 
Where  R5,R0  are  relocatable 

MSG  is  the  assembly  (0  relative)  address  of  the  message 
to  be  output.   The  first  word  contains  the  length 
of  the  message  (in  bytes). 
Return 

R0,R3  destroyed 


MESSAG:   MOV 
ADD 

ADD 

ADD 

MOV 

MOV 


XRBW: 
MSG1: 


.WRITE 
MOV 

MOV 

RTS 

.WORD 


(R5)+,R0 
R0,XRBW+2 

R0,XRBW+10 

@#JOBORG,  RO 

(R0),XRBW+6 

#XRBW,  R3 

#2-XRBW,XRBW+2 

#2-XRBW,XRBW+10 

R5 


;Get  pointer  to  the  message 
;Set  XRPTR  in  write  XRB 

;Set  XRLOC 

;Get  absolute  pointer  to  message 

;Load  byte  count 

;Get  relative  pointer  to  XRBW 

; Output  message 
;Reset  XRPTR 

; Re set  XRLOC 

; Return 


MSG1ND' 
.ASCII 
MSG1ND:   .ASCII 
.EVEN 

MSG2 :  MSG2ND 
.ASCII 

MSG2ND:  .ASCII 
.EVEN 


0,  2 -XRBW,  0,  0,  2 -XRBW,  0 

-MSG1  -  1 
/THIS  IS  THE  FIRST  MESSAGE/ 

A/ 


-  MSG2  -  1 

/ISN'T  IT  A  BEAUTIFUL  DAY/ 

hi 


Example  V.2  A  Routine  to  Output  a  Message  on  the  Teletype 
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the  present  pointer  to  the  file  is  unchanged.  Example  V.3  is  a  routine 
to  read  an  arbitrary  block  of  a  disk  file. 
D.  Errors 

1.  EOF.  An  end-of-file  (Error  #26)  is  returned  when  a  user  tries  to 
read/write  past  the  end  of  a  file  or  from  a  device  on  which  an 
end-of-file  separator  is  encountered.  All  errors  are  returned  in 
the  second  word  of  the  job  data  block  which  is  pointed  to  by  the 
system  variable  IOSTS. 

2.  NOTOFN  (Error  #22)  is  returned  when  the  user  attempts  to  perform 
an  I/O  transfer  to  an  unopened  channel. 

3.  PRTVOL  (Error  #2^)  is  returned  when  the  user  attempts  to  operate 
on  a  file/device  which  is  protected  from  him.   He  may  either  be 
trying  to  access  a  file  belonging  to  another  UED  which  is  protected 
or  doing  something  brilliant  like  reading  from  the  line  printer. 

A  PRIVOL  error  is  also  returned  when  a  user  attempts  to  write  to  a 
file  which  another  user  currently  has  open. 
h.      NOTAVL  (Error  #20)  is  returned  when  the  user  attempts  to  get  a  device 
which  is  currently  servicing  another  user. 

5.  DATERR  (Error  #32)  is  returned  if  there  is  a  device  malfunction  or 
data  error. 

6.  HNGDEV  (Error  #3^+)  indicates  that  a  device  is  not  available  to  the 
system,  e.g.,  it  may  be  off-line. 


MS 


XRB: 

.WORD 

XRCI: 

.WORD 

XRPAR: 

.WORD 

BUT: 

.=.+1000 

0,  BUR -XRB,  1000,  0,  BUF-XRB 

0 

0 


;This  routine  will  read  the  disk  block  specified  in 

;the  variable  BLOCK  from  the  file  opened  on  the 

; channel  given  in  CHNNL.   Data  will  be  placed  in  a  buffer 

;beginning  at  BUR.   In  case  of  error,  the  return  is  to  ERROR. 


READER :   MOV 

CHNNL,  XRCI 

? 

MOV 

BLOCK,  XRPAR 

. 

MOV 

#XRB,  R3 

i 

.FIND 

'■> 

TST 

XRPAR 

? 

BME 

ERROR 

5 

.READ 

5 

CLR 

XRB+6 

> 

MOV 

XRB+2,  XRB+10 

MOV 

@#IOSTS,  Rl 

5 

TST 

(Rl) 

5 

BNE 

ERROR 

J 

Set  channel  index  for  operation 
This  is  the  disk  block 

Set  relative  offset  from  start  of  job  to  XR] 
Point  to  the  block  we  want 
Did  we  get  it? 

No — either  not  a  valid  file  or  no  such  bloc] 
Yes — read  the  block 
Reset  byte  count  for  later  try- 
Reset  pointers  for  later  use 
Get  our  i/O  status 
Any  errors 
Too  bad 


Example  V-3  Finding  and  Reading  a  Particular  Disk  Block 
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VI.  Special  EMT  Functions 

A.   .ANCHR  (EMT  112) 

Anchor  mode  is  used  to  allow  programs  to  be  attached  to  specific 
locations  in  core  and  to  force  the  system  to  swap  jobs  into  the  same 
position  in  core  each  time  (see  section  III.G). 

In  order  to  operate  properly,  after  a  user  has  been  achored,  he  must 
force  himself  to  be  swapped  out  so  that  the  system  will  have  a  chance  to 
reposition  him.   This  is  best  accomplished  by  increasing  his  core  allocation. 
The  user  places  the  core  address  (relative  to  the  beginning  of  the  user 
area)  in  Rl  and  executes  a  .ANCHR.   This  will  place  the  user  in  anchor 
mode,  but  will  not  reposition  him  if  he  is  not  already  in  the  correct 
position  (this  is  handled  by  the  monitor  swap  routines);  therefore,  the 
user  should  increase  his  core  size  which  will  cause  him  to  be  swapped 
out  and  brought  in  at  the  correct  place.   It  Is  the  user's  responsibility 
to  see  that  his  anchor  request  is  a  valid  one  (i.e.,  he  does  not  want. to 
anchor  a  2K  job  in  the  top  IK  of  core).   Also  note  that  the  necessity  of 
increasing  size  prevents  the  user  from  anchoring  a  job  to  the  highest  core 
block.  A  user  who  wishes  to  anchor  a  IK  job  may  increase  his  size  to  2 
to  cause  the  swap  and  then  reduce  his  size  to  the  desired  IK. 

Again  note  that  anchor  mode  should  be  avoided  if  at  all  possible. 

B.   .BREAK  (EMT  66) 

When  users  execute  long  sections  of  code  which  may  cause  the  system  to 
fail  to  act  on  clock  interrupts  (e.g.,  many  disk  accesses),  the  user 
should  inform  the  system  that  he  can  be  swapped  if  there  is  another  job 
ready  to  run.   In  general,  users  should  return  to  the  system  after  k   or 
5  "consecutive"  disk  accesses.   The  user  does  this  by  simply  executing 
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a  .BREAK.   No  parameters  are  necessary.   This  will  cause  the  system  to 
save  the  job  and  run  the  scheduler.   If  no  other  jobs  are  pending, 
control  will  return  immediately  to  the  user. 
C.   .CORE  (EMT  56) 

This  is  a  call  to  the  system  core  allocation  routine.   It  may  be  called 
any  time  the  user  needs  additional  core  or  has  core  to  return  to  the 
system.   The  core  allocater  is  called  by  executing  a  .CORE  with  the 
size  which  the  user  wishes  to  be  in  RO.   On  return,  RO  will  contain 
zero  to  indicate  success.   Requests  for  size  zero  are  ignored.   If  the 
request  is  for  more  than  the  maximum  possible  size,  the  request  is 
ignored.   Size  is  counted  in  blocks  of  ^OOOo  bytes. 

When  the  user  wishes  to  return  core  to  the  system,  the  core  will  be 
removed  from  the  end  (higher  addresses)  of  his  job.  He  will  not  be 
swapped,  and  will  return  to  execution  immediately. 

When  the  user  wishes  to  increase  his  size,  the  system  will  swap  him  out 
and  the  next  time  he  runs,  he  will  be  brought  in  at  his  new  size;  thus, 
he  must  be  swappable  at  the  time  of  the  EMT.   Should  he  be  locked  in 
core  at  the  time,  results  are  unpredictable. 
D.   .DAR  (EMT  62)  and  .DAW  (EMT  6k-) 

This  is  a  routine  to  handle  direct  access  disk  requests.   The  user  may 
read  (write)  to/from  the  disk  without  going  through  the  normal  read/write 
processor.   To  do  this  he  must  set  up  a  pointer  in  Rh-   to  the  File  Control 
Block  of  the  file  he  wishes  to  use  (the  file  must  be  open  in  order  to 
operate  on  it).   Before  executing  the  .DAR  (.DAW)  the  user  must  place 
the  relative  core  address  for  the  transfer  at  FCETC(=l6)  in  the  FCB;  the 
number  of  blocks  to  transfer  is  placed  at  the  byte  FCBC(=2).   FCNLB(=6) 
in  the  FCB  points  to  the  block  number  of  the  file  for  the  operation 
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(the  first  block  is  block  zero,  each  access  causes  FCNLB  to  be 
incremented  by  one).   Before  allowing  the  disk  transfer  to  proceed, 
the  system  will  still  check  to  see  that  the  user  is  permitted  access  to 
this  file.   (See  example  VI. 1.) 

E.  .EXIT  (EMT  76) 

This  routine  causes  the  termination  of  the  user  job.  No  parameters  are 
necessary.   The  system  will  simulate  the  typing  of  a  tC  by  the  user.  A 
.EXIT  causes  all  I/O  buffers  belonging  to  the  user  job  to  be  flushed, 
thus,  terminating  any  i/o  in  progress  by  the  job.  When  a  routine  must 
wait  on  the  completion  of  some  i/o  before  exiting,  it  should  execute  a 
.STALL  then  a  .EXIT. 

F.  .HOIST  (EMT  11*0 

A  user  who  has  been  executing  in  anchor  mode  and  no  longer  needs  this 
facility  should  execute  an  EMT  .HOIST  to  terminate  anchor  mode.   No 
parameters  are  necessary  and  no  damage  is  done  if  the  user  is  not  really 
in  anchor  mode. 
0.   .LOCK  (EMT  60)  and  .UNLCK  (EMT  10*0 

.LOCK  is  used  when  a  routine  must  not  be  swapped  out  of  core  for  some 
reason  (e.g.,  he  wants  to  use  the  system  loader).   No  parameters  are 
necessary.   The  user  should  use  .LOCK  only  when  absolutely  necessary 
and  then  must  unlock  himself  as  soon  as  possible.   .UNLCK  will  free  a 
user  who  is  locked  in  core;  it  requires  no  parameters.   Since  the  process 

jobs  for  lack  of  available  core  space,  users  are  requested  to  execute 
a  .BREAK  after  executing  .UNLCK. 

Execution  of  a  .LOCK  when  a  user  is  already  locked  in  core  or  a  .UNLCK 
when  a  user  is  not  locked  in  core  has  no  effect. 
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START: 


IOSTS 

=    XX 

JOBDA 

=    XX 

FCETC 

=  16 

FCBC 

=  2 

CHOTL 

=  nn 

BLKS 

• 

=  nn 

* 

• 

MOV 

@#JOBDA,  Rk 

MOV 

(■Rk),nk 

MOV 

@CHML(BiO,BA 

MOV 

#CORBUF,    FCETC  (R^) 

MOVB 

#BLKS,FCBC(R^) 

.DAE 

MOV 

@#I0STS,R5 

TST 

(R5) 

BEE 

ERROR 

; System  i/O  status  pointer 

; System  pointer  to  job  data  "block 

;FCB  offset  to  core  address 

;FCB  offset  to  #  blocks  to  transf 

; Channel  index  on  which  file  is  c 

;Number  of  blocks  to  transfer 


;Get  pointer  to  job  data  block 

;Get  pointer  to  i/O  block 

;Get  pointer  to  FCB 

;Load  relative  core  address  for 

;transfer 

;Load  #  of  blocks  to  be  transfer! 

;Read  them  in 

;Get  pointer  to  i/O  status 

;Any  errors 

;Yes 

;No 


CORBUF: 


.  =  .+ 


2000 


; Buffer  for  transfer 
; Length  =  #BLKS*1000 


Example  VI. 1  Use  of  Direct  Access  Read  -  DAR 
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H.   .NAME  (EMT  116) 

A  user  may  assign  a  name  to  a  program  by  placing  the  name  he  wishes 
assigned  in  Rl  and  executing  an  EMT  .NAME.  When  the  user  job  terminated 
(either  normally  or  via  a  system  abort)  the  name  will  be  removed.  Names 
should  only  be  used  when  informing  the  system  that  a  user  is  executing 
a  program  which  requires  some  special  service  on  the  part  of  the  system. 
I.   .STALL  (EMT  102) 

It  is  sometimes  a  good  idea  for  a  routine  to  wait  for  a  period  of  time 
before  executing  more  code  (e.g.,  it  wishes  to  open  the  line  printer 
which  is  currently  in  use).   The  routine  may  place  a  number  of  seconds 
to  wait  in  Rl  and  execute  a  .STALL.   This  will  cause  the  job  to  be  blocked 
for  the  number  of  seconds  specified. 

The  use  of  .STALL  is  much  better  than  sitting  in  a  null  loop  since  the 
user  is  not  using  CPU  time.   .STALL  should  also  be  used  when  the  user 
wants  to  close  a  device  which  may  be  in  the  process  of  physical  output. 
Since  the  close  routine  will  cause  a  device's  output  buffers  to  be 
flushed,  it  is  possible  that  output  will  be  lost;  consequently,  a  job 
that  wants  to  close  a  device  to  which  he  has  just  finished  output  should 
stall  for  a  few  seconds  before  executing  the  close.   (Figure  VI. 1  gives 
suggested  times  for  stalling  for  each  device.) 
J.   .TTAPE  (EMT  7k)   and  .TTRST  (EMT  72) 

Sometimes  it  is  necessary  to  read  paper  tape  through  the  low  speed  reader 
on  the  ASR-33  teletype.  When  the  user  wishes  to  do  this,  he  would 
usually  like  to  suppress  the  echo  and  ignore  any  rubouts  on  the  tape. 
He  may  also  wish  to  do  the  same  processing  for  the  input  from  the 
teletype  keyboard.   This  type  of  transfer  is  called  tape  mode  and  may 
be  reached  by  executing  a  .TTAPE.   No  parameters  are  necessary.  A  .TTRST 
is  used  to  get  out  of  the  mode.   .TTRST  can  also  be  used  to  kill  any 
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Card  Reader 
Line  Printer 
Paper  Tape  Reader 
Paper  Tape  Punch 
Keyboard 
Teletype  Printer 


no  stall  necessary 

3  sees. 

no  stall  necessary 

3  sees. 

no  stall  necessary 

l/lO  sec/character  /max  number  of  output 

characters --to  a  maximum  of  12  sec. 


Figure  VI. 1  Suggested  Stall  Times  for  Various  Devices 


53 

'no  output  flags'  (e.g.,  tO  typed  on  the  keyboard  -  see  section  VIII. D). 
A  .TTRST  is  useful  when  a  program  wishes  to  inform  the  user  of  some 
abnormal  condition  which  may  have  arisen  during  a  process  which  normally 
requires  so  much  output  to  the  teletype  that  a  user  may  turn  it  off. 

K>   .WAIT  (EMI  70) 

A  routine  may  sometimes  desire  to  wait  on  the  completion  of  some  event 
(e.g.,  typing  of  a  delimiter  at  a  teletype).   The  system  provides  a 
.WAIT  for  this  purpose.  A  .WAIT  has  the  effect  of  causing  the  system 
to  save  the  user's  job  and  run  the  scheduler.   If  there  is  no  other  job 
ready  to  run,  the  effect  of  a  .WAIT  by  itself  is  much  like  a  .BREAK. 
However,  the  user  may  set  a  wait  bit  in  the  system  control  variable 
JBWAIT  which  identifies  an  event  on  which  he  wants  to  wait  (see  section 
II. C 6).   If  he  then  executes  a  .WAIT,  the  system  will  not  restart  him 
until  the  specified  event  has  occurred  (see  example  VI .2). 

L.   .FIND  (EMT  100) 

•FIND  is  used  to  position  a  disk  file  at  a  certain  point  (see  section  V.C). 

M.   .TREAD  (EMT  122) 

.TREAD  is  used  to  read  from  a  teletype  and  if  a  response  is  not  given  in  a 
specified  time,  the  user  program  will  be  awakened.   .TREAD  is  simply  a  .READ 
(pg  k6)   combined  with  a  .STALL  (pg  51 )•   The  user  will  be  awakened  when 
either  is  successfully  completed.   The  user  sets  up  the  parameters  as 
described  for  both  a  .READ  and  a  .STALL  and  executes  a  .TREAD.  When  he  is 
awakened,  he  may  check  the  XRBC  field  of  his  XRB  to  determine  whether  he 
has  received  any  input  from  the  teletype.  Note,  that  no  input  is 
transferred  to  the  user  program  until  a  terminal  character  is  typed  on 
the  teletype. 
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JOB 


=  xx 


;Byte  containing  user  job  index 


JSKEY 
JBWAIT 


=  20000 
=  xx 


; Teletype  delimiter  blockage  bit 
;Wait  table  for  user  jobs 


MOVB 
MOV 

@#J0B,  RO 

#JSKEY,  JBWAIT (RO) 

BIC 

#jskey,jbstat(ro) 

.WAIT 

;Get  user  job  index  -  sign  extend 

;Set  bit  to  wait  on  appearance  of 

; delimiter  or  TTY  -  Clear  any  other 

;unit  conditions 

;Make  sure  we  don't  already  have 

;the  bit  set 

;Go  into  wait  -  we  will  be 

; awakened  when  the  user  types  a 

; delimiter  on  his  teletype 


Example  VI. 2  Setting  a  Wait  Condition 
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VII.   Use  of  Interrupts  and  Special  Functions 

A.  Interrupts 

ETS  provides  the  user  with  two  interrupt  vectors  which  he  may  use  as  his 
own.   TRAP  (vector  =  3k)   and  BPT  (vector  =  Ik)   are  maintained  by  ETS  as 
relocated  pointers  into  the  user  area.  Each  time  a  user  routine  is 
saved,  the  contents  of  these  two  vector  locations  are  saved  with  the 
relevant  job  information  to  he  restored  and  relocated  when  the  job  is 
restarted. 

B.  CNTL  V  (tV) 

Many  times  students  will  request  the  performance  of  special  functions 
from  a  user  job  which  will  cause  results  they  had  not  expected  (e.g., 
lengthy  interpretation).   Since  it  is  often  desirable  to  stop  the  given 
process  without  killing  the  job  (especially  if  the  abnormal  termination 
of  the  job  can  damage  a  file),  ETS  provides  a  character  tV  which  can  be 
used  as  a  communication  flag  between  the  user  and  the  running  job. 
When  a  tV  is  typed  at  the  user's  teletype,  ETS  sets  bit  0  in  the  variable 
USRFLG  which  the  running  job  should  interrogate  periodically.   The  job 
is  responsible  for  clearing  the  bit  to  indicate  to  ETS  that  it  has 
noticed  it.   The  action  taken  on  the  occurrence  of  a  tV  is  generally 
an  abort  of  some  type.   The  job  may  either  return  to  the  system  or  ask 
for  input  from  the  user  to  determine  the  reason  for  the  tV. 

C.  CNTL  Q  (tQUIT) 

With  two  exceptions,  t  Q,  works  exactly  like  tV.   t  Q,  sets  bit  15  of  USRFLG, 
and  by  system  convention,  tQ,  is  a  request  by  the  user  for  the  program  to 
terminate  its  processing  and  return  to  the  monitor  via  a  .EXIT. 
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VIII.   System  Service  Routines 

The  following  are  routines  which  the  system  uses  for  some  of  its  own 
processing,  but  which  might  be  useful  to  users  running  under  the  system. 
The  routines  are  compatible  with  a  user's  requirements  of  dynamic  relocata- 
bility.   In  general,  they  may  clobber  one  or  more  registers  and  will  pass 
parameters  in  the  other  registers.   It  is  the  user's  responsibility  to 
save  his  own  registers  and  to  see  that  appropriate  parameters  are  passed. 

Since  the  position  of  these  routines  is  dependent  on  the  version  of 
the  system  in  use,  users  are  cautioned  against  running  programs  on 
separte  versions  of  the  system  without  checking  the  new  definitions  of 
the  routine  names.   Example  VIII. 1  uses  many  of  these  routines. 

A.  SETDDB 

This  is  a  routine  to  load  the  TTY  Device  Data  Block  address  in  Rl  and 

the  TTY  line  index  in  RO.  While  users  may  find  little  direct  use  for 

this  routine,  it  is  good  for  setting  up  parameters  required  by  OCTIN 

and  NAME IN. 

Call: 

JSR   PC, SETDDB 

;no  parameters  are  necessary 

Return: 

;R0  contains  the  TTY  Line  Index 

;R1  points  to  the  TTY  DDB 

;no  additional  registers  are  clobbered 

B.  OCTOUT 

This  routine  will  output  the  octal  number  in  R5  onto  the  teletype.   The 
number  will  be  followed  by  a  <CR>  <LF>.   In  order  to  output  the  characters 
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=  XX 

=  XX 

=  XX 

=  XX 

=  XX 

=  XX 

=  XX 

=  XX 

=  XX 

=  20000 

=  10 

=  k 

=   1 

=  10^050 

=  1+ 

=  0 


Byte  containing  job  index 

Blockage  table 

Unblock  table 

Register  relocation 

System 

Routines 

and 

Variables 

Entry  point  for  system  error  message  handler 

TTY  delimiter 

Open  function 

Byte  offset  in  FIRAB  to  channel  index 

Invalid  command  error  message 

EMT  to  call  file  processor 

I0T  to  buffer  allocator 

Buffer  return  parameter 


@#T0B,  R0 
#JSKEY,JBWAIT(R0) 

#jskey,jbstat(ro) 

@#REGREL+5 
FC,@#SETDDB 
R5,@#SETFQ 
0PNFQ 

PC,@#NAMEIN 

ERR 

PC,@#0CTIN 

ERR 

R2 

#-7-1,  R2 

R2,FQFIL(R^) 

@#I0STS,R2 
(R2),R2 
ERR1 


Get   Job  index  -  sign  extend 

Set  blockage    -  we  wait   for  the  user  to  type  a  line 

And  make  sure  we  wait 

Begin  wait 

Mark  R5  as  relocatable 

Load  pointers  to  TTY  DDB 

Get  a  FIRQB  -*  R^+  and  load 

OPEN  function 

Get  a  name  and  pack  in  FIRQB 

Didn't  get  a  good  one 

Get  a  channel  number 

Didn't  make  it 

Convert  to  channel  index 

Make  it  legal  (0-7) 

Store  it  in  FIRQB 

Try  the  open 

Get  pointer  to  i/O  status 

Get  error  code 

Error  -  too  bad 

No  error  FIRQB  was  not  returned 


#BADCMD,  R2 
PC,@#SIMESlf 


; Choose  our  own  error  code 

; Output  error  message  -  R2  contains  # 

; Return  the  FIRQB 


Example  VIII. 1  Accepting  a  File  Name  and  Channel  From 
the  Teletype  and  Trying  to  Open  it 
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OCTOUT  needs  parameters  set  up  and  calls  SETDDB  to  do  it. 

Call: 

JSR    PC, OCTOUT 

;R5  contains  the  number  to  be  output 

Return: 

;R0  contains  the  TTY  Line  Index 
;R1  points  to  the  TTY  DDB 
;R2, R5  clobbered 

C.  SETFQ 

SETFQ,  is  a  routine  to  set  up  a  FIRQB  for  use  in  file  processor  calls. 

SETFQ,  allocates  a  system  buffer  and  stores  in  it  the  user's  job  number 

and  the  function  requested. 

Call: 

JSR    R5,  SETFQ 

+      FTMFQ 

;FUNFQ,  is  the  FIP  function  desired 

;R5  should  be  marked  relocatable 

Return: 

;R^  will  point  absolutely  to  the  FIRQB 
;R0  clobbered 

When  the  user  has  finished  with  the  FIRQB,  he  must  return  it  to  the  system. 

D.  SIMESS 
SIMESS  is  a  routine  to  retrieve  a  message  from  the  system  message  file 
and  output  It  on  the  teletype.   There  are  two  entry  points  to  SIMESS,  the 
first  will  request  a  message  from  the  teletype  for  outputting.   The 
second,  and  more  useful,  will  accept  a  message  code  in  R2  and  output  the 
corresponding  message. 
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Call: 

JSR    PC, SIMESS     or     JSR    PC,  SIMES4 

;a  message  code  is  supplied  in  R2  when  using 

;SIMES^ 

;a  message  code  will  be  accepted  from  the  teletype 

;when  using  SIMESS 

Return : 

;R0,R1,R2,R4,R5  clobbered 

E.  ENDTST 

ENDTST  is  a  routine  to  determine  if  a  character  is  a  terminal.   Terminal 

characters  are  <space>,  <CR>,  <LF>,  <ALTMODE>,  or  <JO. 

Call: 

JSR  PC,ENDTST 

;R2  contains   the   character  to  be  tested 

Return: 

;Z=1  if  R2  contains  a  terminal  character. 

F.  OCTIN 

OCTIN  is  a  routine  to  input  an  octal  character  from  the  teletype.   It  will 

pick  up  characters  from  the  teletype  and  skip  over  any  initial  "terminals." 

When  it  encounters  a  non-terminal,  it  will  attempt  to  interpret  it  as  an 

octal  character.   It  will  continue  accepting  characters  from  the  teletype 

until  it  encounters  another  terminal  or  a  comma.   If  it  encounters  a 

non-octal  character,  it  will  ignore  it  and  continue  processing;  however, 

it  will  return  a  flag  to  indicate  that  the  number  was  invalid.   In  case 

of  overflow,  high  order  bits  are  truncated.  No  flag  is  returned. 

Call: 

JSR    PC,  OCTIN 

;R1  contains  the  DDB  address  (use  SETDDB) 

Return: 

;R2  contains  the  octal  value 

;R3,R5  clobbered 

;V=1  if  error  or  no  characters  were  found 

;C=1  if  a  bad  character  was  encountered 
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Note  that  OCTIN  does  not  issue  a  read  from  the  teletype  but  accepts 
characters  from  the  monitor  chain  buffers;  consequently,  the  user  program 
should  set  the  delimiter  wait  bit  and  execute  a  .WAIT  before  calling  OCTIN.  If 
the  buffers  are  empty,  an  error  (V=l)  is  returned. 

G.   NAMEIN 

NAMEIN  is  a  similar  routine  to  OCTIN  but  it  is  used  to  pick  up  a  character 
string  and  pack  it  in  a  FIRQB.   In  picking  up  the  name,  NAMEIN  skips  any 
leading  terminators  and  then  stops  on  the  first  occurrence  of  any  later 
terminator.   Before  calling  NAMEIN,  the  user  must  allocate  a  FIRQB  for 
use  in  a  file  call. 
Call: 

JSR    PC,  NAMEIN 
Bh   points  to  a  FIRQB  (a  function  need  not  be  loaded) 
R0  points  to  a  TTY  Line  Index  (use  SETDDB) 
Rl  points  to  a  TTY  DDB  (use  SETDDB) 

Return: 

;V=1  if  there  was  no  name  in  the  TTY  buffer 
;R2,R3,R5  clobbered 

;File  name  is  packed  RAD 50  in  the  FIRQB  at  the 
appropriate  places  -  see  CSIFQ  (section  IV.C13) 

H.   BUFFER 

BUFFER  is  a  routine  to  allocate  or  deallocate  a  l6  word  system  buffer. 
The  call  to  the  buffer  allocater  is  an  IOT  which  requires  one  parameter. 
Call: 

BUFFER     (=I0T) 

PARM 

;PARM  =  GETSML  =  200  for  allocate 

;PARM  =  RETSML  =  000  for  deallocate 

;~Rk   points  to  the  buffer  on  deallocation 
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Return : 

;~Rk   points  to  the  buffer  on  allocation 
;V=1  if  no  buffers  remain 
;No  registers  clobbered 

I.   CLRBUF 

CLRBUF  is  a  useful  routine  for  emptying  the  user's  TTY  chain  buffers. 

On  call,  all  remaining  characters  in  the  input  or  output  buffer  will  be 

flushed. 

Call: 

JSR    R5,  CLRBUF 

+      X 

;X  =  TT044  =  26  for  output  buffers 

;X  =  TTH4  =  Ik   for  input  buffers 

;R1  points  to  the  TTY  DDB 

;R5  should  be  marked  relocatable 

Return : 

;R3,  R5  clobbered 


Index 
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.ANCHR,  21,  47 
.BREAK,  20,  47 
.CORE,  48 
.DAR,  48 
.DAW,  48 
.EXIT,  49 

.FIND,  42,  46,  53 

.HOIST,  21,  49 
.LOCK,  49 
.NAME,  23,  51 
.READ,  36,  46 
.STALL,  49,  51 
.TREAD,  46 
.TTAPE,  41,  51 
.TTRST,  41,  51 
.UNLCK,  49 
.WAIT,  53 
.WRITE,  36 

ABORT,  10 

Absolute  Pointers,  12,  14,  15 

Altmode,  41 

Anchor  Mode,  21,  22,  47,  49 

ASCII  String,  31 

ASCII,  30,  37 

BADCMD,  10 

BADDIR,  10 

BADNAM,  10 

Binary  Data,  37 

BPT,  55 

Buffer  Allocation 

Deallocation,  21,  60 
BYEFQ,  28 
CALFIP,  24 
Card  Reader,  36,  38 
Carriage  Return,  39 
Channel,  2,  34 
CKSMER,  10 
CLRBUF,  6l 
CLSFQ,  27 
CNTL  B,  41 
CNTL  C,  39,  49 
CNTL  0,  41 
CNTL  Q,  41,  55 
CNTL  U,  41 
CNTL  V,  41,  55 
CNTL  Z,  41 
COMWRD,  11,  15 

Conditional  Relocation,  13,  15 
Control  Block,  4 
Core  Allocation,  48 
CREFQ,  27 
CSIFQ,  29 
DATERR,  10,  45 


DELFQ,  27 

Device  Data  Block,  4,  7 

DIRFQ,  28 

Dispatch  Table,  18 

Dynamic  Relocatability,  2,  12,  21 

ENDTST,  59 

EOF,  10,  36,  42,  45 

ERRFQ,  28 

Error  Codes,  10,  33,  45 

EXTFQ,  24,  42 

FCASN,  6 

FCBC,  6 

FCETC,  6 

FCFLI,  6 

FCNLB,  42 

FCPNB,  6 

FCPW,  6 

FCSIZ,  6 

FCSTS,  6 

FCTYPE,  6 

FCWND,  6 

File,  4 

File  Control  Block,  6 

File  I/O,  42 

File  Request  Queue  Block  (see  FIRQB) 

File  String,  26,  29 

FIRQB,  24,  26,  27,  28,  30 

FNDFQ,  33 

Form  Feed,  37,  4l 

FQBLCK,  25,  29 

FQCKSM,  25,  29 

FQDEVN,  25,  29,  33 

FQDEV,  25,  29,  33 

FQERNO,  25,  28 

FQFIL,  25,  29,  33 

FQFUN,  25 

FQJOB,  25 

FQLEN,  25,  29,  30 

FQjmMl,  25,  27,  28,  29,  33 

FQNAM2,  25,  27,  28 

FQPPN1,  25,  28,  29 

FQPPN2,  25 

FQPROT,  25 

FQPTR,  25,  29,  30 

FQSIZ,  24,  25,  27 

FQSTRT,  25,  29 

HNGDEV,  10,  45 

Input-Output  Control  Block 
(IOB),  2 

Interrupts,  55 

INUSE,  10 
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I  OB,  k 

IOF,  19 

ION,  19 

IOSTS,  9,  33,  ^5 

JBSTAT,  9 

JBWAIT,  9,  53 

JDANCR,  3 

JDCPU,  3 

JDDEV,  3 

JDFLG,  3 

JDIOB,  3 

JDIOST,  it- 

JDKCT,  3 

JDNAME,  3 

JDPPN,  3 

JDSGMX,  3 

JDSGNW,  3 

JDSIZ1,  3 

JDSIZO,  3 

JDSP,  3 

JDUFD,  3 

JOB,  2 

Job  Data  Block  (JDB),  3 

Job  Termination,  ij-9 

JOBDA,  2 

Line  Feed,  37,  39 

Line  Printer,  37,  kO 

LOAFQ,  29 

Named  Code,  23 

NAMEIN,  60  . 

NOLOAD,  10 

NOROOM,  10,  27 

NOSUCH,  10,  33 

NOTAVL,  10,  k5 

NOTCLS,  10 

NOTFND,  10 

NOTOPN,  10,  33,  k  5 

Octal  String,  31 

OCTIN,  59 

OCTOUT,  56 

OPENFQ,  27 

OUTRNG,  10 

Papertape  Punch,  36 

Papertape  Reader,  36 

Parameters,  Card  Reader,  J>k 

Parm,  31 

Parm  List,  31 

Parm  String,  31 

PRIVOL,  k5,    10 

Processor  Status  Word,    19 

PROFQ,    28 

REGREL,    9,    12 

RELPTR,    15 

RENFQ,    27 

RSTFQ,    29 


Rub outs,   37,   kl 

Serial  Device,  36 

SETDDB,  56 

SETFQ,  58 

SIMESS,  58 

Stack,  2,  15 

Stack,  Changing  Size,  17 

Stack,  Data,  19 

Stack,  Overflow,  17 

STKBAS,  17 

SWIFQ,  30 

Switch,  31 

Switch  List,  30,  31 

Switch  String,  30,  31 

Tab,  37,  hi 

Teletype,  39 

Transfer  Control  Block  (see  XRB) 

TRAP,  55 

UFD,  28 

USRFLG,  11,  12,  Ij.1,  55 

Vertical  Tab,  37,  hi 

Wait  Condition,  ^h 

XRB,  3^,  36,  38,  k2 


BLIOGRAPHIC  DATA 
EET 


1.   Report  No. 

UIUCDCS-R-72-523 


3.  Recipient's  Accession  No. 


5-  Report  Date 

May,    1972 


Title  and  Subtitle 

ETS  System  User's  Guide 


Author(s) 


Donald  W.    Oxley 


8.   Performing  Organization  Rept. 
No. 


Performing  Organization  Name  and  Address 

Department  of  Computer  Science 
University  of  Illinois 
Urbana,  Illinois  61801 


10.  Project/Task/Work  Unit  No. 


11.  Contract /Grant  No. 

GJ-812 


Sponsoring  Organization  Name  and  Address 

National  Science  Foundation 
Washington,  D.  C. 


13.  Type  of  Report  &  Period 
Covered 

Research 


14. 


Supplementary  Notes 


Abstracts 


This  manual  is  intended  to  serve  as  a  reference  to 
persons  who  wish  to  write  programs  for  use  under  the 
Educational  Timesharing  System  -  ETS.   It  discusses  in 
detail  the  conventions  and  facilities  used  or  supported  by 
ETS.   It  assumes  some  familiarity  with  ETS  and  a  thorough 
understanding  of  the  PAL-11  assembly  language. 


Key  Words  and  Document  Analysis.    17a.  Descriptors 


Identifiers/Open-Ended  Terms 


It  COSAT1  Field/Group 


UAvailability  Statement 

Unlimited  Release 


19..  Security  Class  (This 
Report) 

,.   -    UNCLASSIFIED 

20.  Security  Class  (This 
Page 

UNCLASSIFIED 


21-  No.  of  Pages 

63 


22.  Price 


't'M  NTIS-35   (10-70) 


USCOMM-DC    40329-P7  1 


<*i/c 


>are 


m 


m      m         m 

Boat  WWM      '•};(:> 

m     ■ 

Hi 


Hi 


